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Description 

[0001 ] This invention relates generally to detecting the 
presence of malicious code in computer files, and more 
particularly to improving the performance of malicious 
code detection methods. 

[0002] During the brief history of computers, system 
administrators and users have been plagued by attacking 
agents such as viruses, worms, and Trojan Horses, 
which may be designed to disable host computer sys- 
tems and propagate themselves to connected systems. 
[0003] In recent years, two developments have in- 
creased the threat posed by these attacking agents. First- 
ly, increased dependence on computers to perform mis- 
sion critical business tasks has increased the economic 
cost associated with system downtime. Secondly, in- 
creased interconnectivity among computers has made it 
possible for attacking agents to spread to a large number 
of systems in a matter of hours. 

[0004] Attacking agents can infect a system by replac- 
ing the executable code stored in existing files. When the 
system attempts to execute the code stored in these files, 
it instead executes malicious code inserted by the attack- 
ing agent, allowing the attacking agent to gain control of 
the system. Virus scanning utilities, such as Norton An- 
tivirus, produced by Symantec Corporation of Cupertino, 
California, allow a user to determine whether a file con- 
taining executable code has been infected with malicious 
code. 

[0005] Traditionally, these utilities have been able to 
detect viruses by checking for suspicious sections of 
code in designated locations or looking for other easily 
detectable characteristics. These methods can be per- 
formed quickly, with little burden to system resources. 
[0006] However, as attacking agents have become 
more sophisticated, scanning utilities have needed to 
perform even more complicated tests to detect the pres- 
ence of malicious code. For example, special purpose 
code may have to examine large portions of a file or per- 
form complicated emulation techniques to detect the 
presence of viruses. 

[0007] These techniques must often be performed se- 
rially, and are extremely time and resource intensive. Op- 
timizing these routines sufficiently to prevent them from 
becoming prohibitively time consuming when applied to 
a large number of files is becoming extremely difficult as 
attacking agents grow in number and complexity. What 
is needed is a way to improve the speed and reliability 
of detection techniques. 

WO 00/28420 describes scanning a file with an antivirus 
module and storing in a critical sectors file a hash for 
each scanned sector, a date of a most recent update of 
the module and a version number of the module. The 
critical sectors file is transmitted with the file to a recipient 
computer where the hash value is recalculated and com- 
pared with the stored value. 

Aspects of the present invention are set out in the ap- 
pended independent claims. 



[0008] Embodiments of the present invention com- 
prise methods, systems and computer readable media 
for determining whether a compute file (340) has been 
infected by an attacking agent. A scanning engine (205) 

5 generates a new hash of a critical viral target region of 
the file (340) and compares it to a stored hash of the 
critical viral target region. For each attacking agent, the 
scanning engine (205) determines whether the file (340) 
has been scanned by the most recent Version of a de- 

10 tection module (425) associated with the attacking agent. 
If the hashes are identical and the file (340) has been 
scanned by the most recent version of the detection mod- 
ule (425), the scanning engine (205) determines that the 
file (340) is free of infection by the attacking agent. 

15 

Brief Description of the Drawings 

[0009] These and other more detailed and specific ob- 
jects and features of the present invention are more fully 
20 disclosed in the following specification, reference being 
had to the accompanying drawings, in which: 
[0010] Figure 1 is a high level block diagram illustrating 
a computer system 1 00 on which malicious code may be 
detected. 

25 [0011] Figure 2 is a block diagram illustrating a closer 
view of the memory 1 06 and the storage 1 08 of the com- 
puter system 100 of Figure 1 . 

[001 2] Figure 3 is a block diagram Illustrating an entry 
300 in a scanning history database 215. 
30 [0013] Figure 4 is a block diagram illustrating a closer 
view of a scanning engine 205. 

[0014] Figure 5 is a flow chart illustrating a preferred 
embodiment of the present invention. 

35 Detailed Description of the Preferred Embodiments 

[0015] An embodiment provides for determining 
whether a file 340 contains malicious code by checking 
a hash of a critical viral target region (CVTR) 
40 [0016] As used herein, a CVTR refers to a region of a 
file 340 that is usually Changed when the file 340 is in- 
fected with malicious code. CVTRs may be specific to a 
file 340 and can include the executable file header; the 
region around a main program entry point, the relocation 
45 of the file 340, or any section of the file 340 that would 
likely be modified by an attacking agent. A file may in- 
clude multiple CVTRs, each associated with particular 
attacking agents. 

[001 7] As used herein, the term "malicious code" refers 
50 to any program, module, or piece of code that enters a 
computer without an authorized user's knowledge And/or 
against an authorized user's wishes. The term "attacking 
agent" includes Trojan Horse programs, worms, viruses, 
and other such insidious software that insert malicious 
55 code into a file 340. An attacking agent may include the 
ability to replicate itself and compromise other computer 
systems. As used, herein the terms "infected" and "in- 
fection" refer to the process of inserting malicious code 
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in a file. 

[0018] As used herein, a "hash" or "hash function" is 
a one-way function, from a variable sized input to a fixed 
size output that is Substantially collision free. Normally, 
the output is smaller than the input. "One-way" means 
that it is easy to compute the output from the input, but 
computationally infeasible to compute the input from the 
output. "Substantially collision free" means that it is very 
difficult to find two or more inputs that hash to the same 
output. Examples of suitable hash functions usable in the 
embodiment are MDS and a CRC (Cyclic Redundancy 
Check) function. 

[0019] Figure 1 is a high level blockdiagram illustrating 
a computer system 1 00 on which malicious code may be 
detected. Illustrated are a processor 102 coupled to a 
bus 104. There may be more than one processor 102. 
Also coupled to the bus 1 04 are a memory 1 06, a storage 
device 108, a keyboard 1 10, a graphics adapter 112, a 
pointing device 114, and a network adapter 1 1 6. Adisplay 
1 18 is coupled to the graphics adapter 1 12. 
[0020] The processor 1 02 may be any specific or gen- 
eral-purpose processor such as an INTEL x86 or POW- 
ERPC-compatible central processing unit (CPU). The 
storage device 1 08 may be any device capable of holding 
large amounts of data, such as a hard drive, compact 
disk read-only memory (CD-ROM), DVD, or some other 
form of fixed or removable storage device. 
[0021] The memory 106 holds instructions and data 
used by the processor 1 02. The pointing device 1 1 4 may 
be a mouse, touch-sensitive display, or other type of 
pointing device and is used in combination with the key- 
board 110 to input data into the computer system 100. 
The types of hardware and software within the computer 
system 1 00 may vary. 

[0022] Figure 2 is a block diagram illustrating a closer 
view of the memory 1 06 and storage 1 08 of the computer 
system 1 00 of Figure 1 . The memory 1 06 includes ascan- 
ning engine 205 that detects the presence of malicious 
code in the computer system 100. 
[0023] The scanning engine 205 comprises group of 
modules that are stored on the storage 108 and loaded 
into memory 106. As used herein, the term "module" re- 
fers to computer program logic and/or any hardware or 
circuitry utilized to provide the functionality attributed to 
the module. A module may be implemented in hardware, 
software, firmware, or any combination thereof. 
[0024] The scanning engine 205 identifies data to be 
checked for the presence of attacking agents, checks for 
the attacking agents, and, if necessary, responds to a 
detected attacking agent. Typically, the data to be 
checked reside in the storage device 108, the memory 
106, or both. The scanning engine 205, therefore, iden- 
tifies particular files 210 and/or memory locations to be 
checked for attacking agents. Other data that may be 
identified by the scanning engine 205 include emails re- 
ceived or sent by the computer system 100, streaming 
data received from the Internet, etc. The scanning engine 
205 includes a version identifier which is updated when- 



ever a new version of the scanning engine 205 is in- 
stalled. 

[0025] The storage 108 includes executable files 210 
and a CVTR database 215. The executable files 21 0 are 

5 files containing executable code that are executed by the 
computer system 100 to perform various computational 
tasks. The CVTR database 21 5 contains scanning infor- 
mation related to each of the executable files 210. The 
CVTR database 215 preferably stores a CVTR region 

10 310 of each of the executable files 210, a file identifier 
305, and identifiers 320 indicating the most recent ver- 
sion of the scanning engine 205 applied to the file 340. 
[0026] Figure 3 is a block diagram illustrating an entry 
300 in a CVTR database 215. Each entry 300 stores in- 

15 formation about a file 340. The entry 300 includes a file 
identifier 305, which uniquely identifies the file 340 for 
the scanning engine 205. The file identifier 305 can be 
the file name or can be a hash of a unique portion of the 
file 340. Using a hash as an identifier allows the scanning 

20 engine 205 to identify files 21 0 even if the name of the 
file 340 has been changed, maliciously or otherwise. 
[0027] The entry 300 additionally includes a section 
31 0 storing hashes of one or more CVTR regions of the 
file 340. These hashes are generated when the scanning 

25 engine 205 performs a complex scan of the file 340. The 
section 31 0 may include a hash of a single CVTR which 
is used in the detection of all attacking agents. Alterna- 
tively the section 310 may store hashes of multiple 
CVTRs, with each CVTR associated with one or more 

30 attacking agents. Detected changes in a CVTR, such as 
an increase to a size field are indicative of possible in- 
fection by an attacking agent, but may not be useful as 
an indicator of a specific attacking agent. However, the 
absence of change to any CVTR is a reliable indicator 

35 that an attacking agent has not inserted malicious code 
in the file 340. 

[0028] Each entry 300 also includes a complex virus 
detection algorithm version (CVDAV) 320 section. Each 
CVDAV section 320 stores the version of the scanning 
40 engine 205 last used to scan the file 340. When a newer 
version of the scanning engine 205 performs a scan of 
the file 340 for any attacking agent, the CVDAV section 
320 is updated. 

[0029] Figure 4 is a block diagram illustrating a closer 
45 view of a scanning engine 205. The scanning engine 205 
includes a selection module 410. The selection module 
410 determines which tests to apply to the executable 
files 21 0. The selection module 41 0 is configured to eval- 
uate a database entry 300 for the file 340 and determine 
50 which simple detection modules 420 and complex detec- 
tion modules 425 to apply to the file 340. 
[0030] A hash generator 430 is configured to generate 
a hash of a CVTR region of a file 340. The generated 
hashes are compared with the previously generated 
55 hashes 31 0 stored in the CVTR database 215 to deter- 
mine whether the file 340 has changed. 
[0031] The scanning engine 205 includes a group of 
simple detection modules 420. These detection modules 
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420 typically check selected areas of a file 340 for distinct 
code sequences or other signature information. Alter- 
nately, the modules 420 may check the file 340 for dis- 
tinctive characteristics such as a particular size. Each of 
the simple detection modules 420 is associated with a 
particular attacking agent. The scanning engine 205 typ- 
ically applies multiple simple detection modules 420 in 
parallel. 

[0032] The scanning engine 205 additionally includes 
a set of complex detection modules 425. These detection 
modules 425 are configured to perform more advanced 
tests on a file 340 to determine whether malicious code 
is present. For example, a complex detection module 425 
is useful for detecting the presence of a polymorphic en- 
crypted virus. A polymorphic encrypted virus ("Polymor- 
phic virus") includes a decryption routine and an encrypt- 
ed viral body. To avoid standard detection techniques, 
polymorphic viruses use decryption routines that are 
functionally the same for each infected file 340, but have 
different sequences of instructions. Thus, the scanning 
engine 205 cannot detect a polymorphic virus by applying 
one of the simple detection modules 420. Instead, the 
scanning engine 205 uses a complex detection inodule 
425 that loads the executable file 340 into a soft- 
ware-based CPU emulator acting as a simulated virtual 
computer. The file 340 is allowed to execute freely within 
this virtual. computer. If the executable file 340 does con- 
tain a polymorphic virus, the decryption routine is allowed 
to decrypt the viral body. The detection module 425 de- 
tects the virus by searching through the virtual memory 
of the virtual computer for a signature from the decrypted 
viral body. The complex detection modules 425 may also 
be configured to detect metamorphic viruses, that, while 
not necessarily encrypted, also vary the instructions 
stored in the viral body, or any other type of attacking 
agent that cannot be detected through simple signature 
based detection. 

[0033] Typically, each of the complex detection mod- 
ules 425 is associated with a particular attacking agent 
and is equipped to detect its presence, though in alternate 
embodiments multiple detection modules 425 may be 
associated with a single attacking agent, or a single de- 
tection module 425 may be equipped to detect multiple 
attacking agents. 

[0034] Each of the complex detection modules 425 in- 
cludes a version number indicating the last version of the 
scanning engine 205 to contain an updated version of 
the detection module 425. When a new version of the 
scanning engine 205 is installed, the newer versions of 
those detection modules 425 that are updated contain 
the version identifier of the newly installed version of the 
scanning engine 205. This information allows the scan- 
ning engine 205 to determine whether afile 340 has been 
checked with a newest version of a detection module 
425. The scanning engine 205 checks the CVDAV entry 
320 associated with a file 340 to determine the last ver- 
sion of the scanning engine 205 applied to the file 340. 
[0035] Figure 5 is a flow chart illustrating a preferred 



embodiment of the present invention. The process be- 
gins with the scanning engine 205 applying 505 the sim- 
ple detection modules 420 to the file 340 to be scanned. 
Typically, this process is performed until all of the simple 
5 detection modules 420 have been applied to the file 340. 
The hash generator 430 then reads the file 340 and com- 
putes 510 a hash of the critical viral target region of the 
file 340. 

[0036] The selection module 41 0 then determines 520 

10 whether the CVTR database 215 includes an entry 300 
for the current file 340. If the file 340 is not in the database 
215, the selection module 410 applies 525 a complex 
detection module 425 to the file 340. 
[0037] If the file 340 appears in the database 21 5, the 

15 selection module 410 determines 535 whether the file 
340 has been scanned by the newest version of the de- 
tection module 425 by checking the CVDAV section 320 
of the entry 300 corresponding to the file 340 in the CVTR 
database 215 to determine the version of the scanning 

20 engine 205 that was last applied to the file 340. The se- 
lection module 410 then checks the version number of 
the current complex detection module 425 to determine 
the last version of the scanning engine 205 to contain an 
update to the detection module 425. If the version number 

25 of the scanning engine 205 last applied to the file 340 is 
equal or higher than the version number of the most re- 
cent version of the scanning engine 205 to contain an 
update to the detection module 425, the scanning engine 
205 determines that the file 340 has been scanned with 

30 the most recent version of the current detection module 
425. 

[0038] If the selection module 41 0 determines that the 
file 340 has not been scanned by the most recent version 
of the detection module 425, the scanning engine 205 
35 applies 525 the newest complex detection module 425 
to the file 340. 

[0039] If the CVDAV section 320 indicates that the file 
340 was scanned with the current detection module, the 
selection module 41 0 determines 540 whether the CVTR 

40 has changed by comparing the newly generated CVTR 
hash to the hash 310 stored in the CVTR database 215. 
If the selection module 410 determines that the CTVR 
has changed, the scanning engine 205 applies the com- 
plex detection module 425 to the file 340. If the selection 

45 module 41 0 determines that the CVTR has not changed, 
the selection module 410 approves 542 the file as not 
infected by the current attacking agent. The process is 
repeated 545 for each complex detection module 425, 
until the file 340 has been tested for every attacking agent 

50 known to the scanning engine 205. 

[0040] If a complex scan is performed 525 on the file 
340 for any attacking agent, the update module 415 up- 
dates 548 the CVTR database 21 5 to reflect any chang- 
es. The update module 41 5 stores the recently generated 

55 CVTR hash in the hash field 310 and stores the current 
version numberof thescanning engine205 in the CVDAV 
field 320. If no entry previously existed for the file 340, 
the update module 415 creates a new entry 300, stores 
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the recently generated CVTR hash in the hash field 31 0 
and stores the version number of the current scanning 
engine 205 in the CVDAV field 320. The scanning engine 
205 then stops 550 scanning the file 340. 
The present invention can be implemented by acomputer 
program operating on a standard desk top computer. An 
aspect of the present invention thus provides a storage 
medium storing processor implementable instructions for 
controlling a processor to carry out the method as here- 
inabove described. 

Further, the computer program can be obtained in elec- 
tronic form for example by downloading the code over a 
network such as the internet. Thus in accordance with 
another aspect of the present invention there is provided 
an electrical signal carrying processor implementable in- 
structions for controlling a processor to carry out the 
method as hereinbefore described. 
The above description is included to illustrate the oper- 
ation of the preferred embodiments and is not meant to 
limitthe scope of the invention. Thescope of the invention 
is to be limited only by the following claims. From the 
above discussion, many variations will be apparent to 
one skilled in the relevant art that would yet be encom- 
passed by the scope of the invention. 



Claims 

1. A method of operating a system (205,215) for de- 
tecting infection of a computer file (340) by any one 
of a plurality of attacking agents, the method com- 
prising the steps of: 

generating (510) a new hash of a critical viral 
target region of the file; and for each attacking 
agent performing the steps of: 

comparing (540) the new hash of the critical 
viral target region to a previously generated 
hash of the critical viral target region; 
determining (535) whether the file has been 
scanned for infection by the attacking agent 
with a most recent version of a respective 
detection module (425); and 
determining (542) that the file has not been 
infected by the attacking agent when the 
new hash and the previously generated 
hash are identical and the file is determined 
to have been scanned with the most recent 
version of the detection module. 

2. The method of claim 1 , further comprising the step 
of for each attacking agent applying the detection 
module to the file in response to a determination that 
the file has not been scanned by the most recent 
version of the detection module. 

3. The method of claim 2, further comprising the step 



of for each attacking agent updating an indicator of 
a most recent version of a scanning engine applied 
to the file to indicate acurrent version of the scanning 
engine. 

5 

4. The method of claim 1, wherein the step of deter- 
mining whether the file has been scanned for infec- 
tion by the attacking agent with a most recent version 
of the detection module comprises the substeps of: 

10 

determining a most recent version of a scanning 
engine applied to the file; 
determining a most recent version of the scan- 
ning engine to include an updated version of the 
15 detection module; and 

determining that the file has been scanned with 
the most recent version of the detection module 
when the most recent version of the scanning 
engine applied to the file was not created earlier 
20 than the most recent version of the scanning en- 

gine to include an updated version of the detec- 
tion module. 

5. The method of claim 1 , further comprising the step 
25 of applying (525) the detection module to the file in 

response to a determination that the new hash and 
the previously generated hash are not identical. 

6. The method of claim 5, further comprising the step 
30 of replacing (549) the previously generated hash of 

the critical viral target region with the new hash of 
the critical viral target region. 

7. The method of claim 1 , wherein the critical viral target 
35 region includes an executable file header. 

8. The method of claim 1 , wherein the critical viral target 
region includes a start of a relocation section. 

40 9. The method of claim 1 , wherein the critical viral target 
region includes a region around a program entry 
point. 

10. A method as claimed in claim 1 wherein said steps 
45 are preceded by a further step of performing a set 

of high speed scans on the file using acorresponding 
set of simple detection modules (420). 

11. A system for detecting infection of a computer file 
50 (340) by any one of a plurality of attacking agents, 

the system comprising: 

a plurality of detection modules (425) each con- 
figured to check the computer file for infection 
55 by a respective one of the attacking agents, the 

detection module including an identifier of a 
most recent version of a scanning engine (205) 
to include an update to the detection module; 
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a database (215), in communication with the de- 
tection modules, and storing entries, each entry 
associated with a file (340) and containing a pre- 
viously generated hash (310) of a critical viral 
target region and an identifier (320) indicating a 
most recent version of the scanning engine to 
scan the file for the presence of malicious code; 
a hash generator (430), in communication with 
the database, and configured to generate a new 
hash of the critical viral target region; 
a selection module (41 0), in communication with 
the database and the hash generator, and con- 
figured for each attacking agent to: 

compare the new hash of the critical viral 
target region to the previously generated 
hash of the critical viral target region; 
compare the identifier of the most recent 
version of the scanning engine to scan the 
file to the identifier of the most recent ver- 
sion of the scanning engine to include an 
update of the detection module; and 
determine that the file has not been infected 
by an attacking agent when the new hash 
and the previously generated hash are iden- 
tical, and the most recent version of the 
scanning engine to scan the file is not an 
earlier version than the most recent version 
of the scanning engine to include an update 
of the detection module. 

12. The system of claim 1 1 , wherein the selection mod- 
ule is further configured to: 

apply the detection module to the file in response 
to a determination that the most recent version 
of the scanning engine to scan the file is an ear- 
lier version than the most recent version of the 
scanning engine to include an update of the de- 
tection module. 

13. The system of claim 12, further comprising an update 
module (415), in communication with the database 
and with the selection module, and configured to up- 
date the identifier of the most recent version of the 
scanning engine to scan the file to indicate that the 
most recent version of the scanning engine to scan 
the file is the current version of the scanning engine. 

14. The system of claim 1 1 , wherein the selection mod- 
ule is further configured to apply the detection mod- 
ule to the file in response to a determination for the 
respective attacking agent that the new hash and 
the previously generated hash are not identical. 

15. The system of claim 14, wherein an update module 
(415) is configured to update the database to store 
the new hash of the critical viral target region. 



16. A system as claimed in claim 1 1 comprising a set of 
simple detection modules (420) operable to perform 
high speed scans on the file. 

5 17. A computer-readable medium containing computer 
code instructions for controlling a system to carry out 
all of the steps of a method as claimed in any one of 
claims 1 to 10. 

10 18. An electrical signal carrying processor implementa- 
ble instructions for controlling a processor to carry 
out the method of any one of claims 1 to 1 0. 



1. Verfahren zum Betreiben eines Systems (205,215) 
zum Erkennen der Infizierung einer Computerdatei 
(340) mit einem beliebigen, aus einer Vielzahl von 
20 Mitteln zum Angriff auf die Datensicherheit (Angriffs- 
mitteln), wobei das Verfahren folgende Schritte um- 
fasst: 

erzeugen (51 0) eines neuen Hash-Wertes eines 
25 kritischen Virus-Zielbereichs der Datei; und fur 

jedes Angriffsmittel durchfuhren folgender 
Schritte: 

vergleichen (540) des neuen Hash-Wertes 
30 des kritischen Virus-Zielbereichs mit einem 

zuvor erzeugten Hash-Wert des kritischen 
Virus-Zielbereichs; 

feststellen (535), ob die Datei auf Infizierung 
mit dem Angriffsmittel mit einer neuesten 
35 Version eines entsprechenden Erken- 

nungsmoduls (425) gescannt wurde, und 
feststellen (542), dass die Datei nicht mit 
dem Angriffsmittel infiziert ist, wenn der 
neue Hash-Wert und der zuvor erzeugte 
40 Hash-Wert identisch sind und wenn festge- 

stellt wird, dass die Datei mit der neuesten 
Version des Erkennungsmoduls gescannt 
wurde. 

45 2. Verfahren nach Anspruch 1, weiter umfassend den 
Schritt, dass fur jedes Angriffsmittel das Erken- 
nungsmodul auf die Datei angewandt wird, in Ant- 
wort auf eine Feststellung, dass die Datei nicht mit 
der neuesten Version des Erkennungsmoduls ges- 
50 cannt wurde. 

3. Verfahren nach Anspruch 2, weiter umfassend den 
Schritt, dass fur jedes Angriffsmittel ein I ndikator ei- 
ner neuesten Version einer Scan-Engine aktualisiert 

55 wird, die auf die Datei angewandt wird, urn eine ak- 
tuelle Version der Scan-Engine zu kennzeichnen. 

4. Verfahren nach Anspruch 1, wobei der Schritt des 
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Feststellens, ob die Datei mit einer neuesten Version 
des Erkennungsmoduls auf Infizierung mit dem An- 
griffsmittel gescannt wurde, folgende Teilschritte 
umfasst: 

feststellen einer neuesten Version einer 
Scan-Engine, die auf die Datei angewandt wird; 
feststellen einer neusten Version der Scan-En- 
gine, um eine aktualisierte Version des Erken- 
nungsmoduls einzubeziehen; und 
feststellen, dass die Datei mit der neuesten Ver- 
sion des Erkennungsmoduls gescannt wurde, 
wenn die neueste Version der Scan-Engine, die 
auf die Datei angewandt wurde, nicht fruher er- 
zeugt wurde, als die neueste Version der 
Scan-Engine, um eine aktualisierte Version des 
Erkennungsmoduls einzubeziehen. 

5. Verfahren nach Anspruch 1 , weiter umfassend den 
Schritt des Anwendens (525) des Erkennungsmo- 
duls auf die Datei, in Antwort auf eine Feststellung, 
dass der neue Hash-Wert und der zuvor erzeugte 
Hash-Wert nicht identisch sind. 

6. Verfahren nach Anspruch 5, weiter umfassend den 
Schritt des Ersetzens (549) des zuvor erzeugten 
Hash-Wertes des kritischen Virus-Zielbereichs 
durch den neuen Hash-Wert des kritischen Vi- 
rus-Zielbereichs. 

7. Verfahren nach Anspruch 1 , wobei der kritische Vi- 
rus-Zielbereich einen Anfangskennsatz einer aus- 
fuhrbaren Datei enthalt. 

8. Verfahren nach Anspruch 1 , wobei der kritische Vi- 
rus-Zielbereich den Anfang eines Auslagerungsbe- 
reichs enthalt. 

9. Verfahren nach Anspruch 1 , wobei der kritische Vi- 
rus-Zielbereich einen Bereich um einen Programm- 
eintrittspunkt enthalt. 

10. Verfahren nach Anspruch 1, wobei den besagten 
Schritten ein weiterer Schritt vorausgeht, in welchem 
ein Satz von Hochgeschwindigkeitsscans der Datei 
unter Verwendung eines korrespondierenden Sat- 
zes einfacher Erkennungsmodule (420) durchge- 
fuhrt wird. 

1 1 . System zum Erkennen der Infizierung einer Compu- 
terdatei (340) mit einem beliebigen, aus einer Viel- 
zahl von Angriffsmitteln, wobei das System umfasst: 

eine Vielzahl von Erkennungsmodulen (425), 
von denen jedes so konfiguriert ist, dass es die 
Computerdatei auf Infizierung mit einem jewei- 
ligen Angriffsmittel uberpruft, wobei das Erken- 
nungsmodul ein Identifizierungszeichen einer 



neuesten Version einer Scan-Engine (205) ent- 
halt, um eine Aktualisierung des Erkennungs- 
moduls einzubeziehen; 

eine Datenbank (215), die mit den Erkennungs- 
modulen kommuniziert und Eintrage speichert, 
wobei jeder Eintrag einer Datei (340) zugeord- 
net ist und einen zuvor erzeugten Hash-Wert 
(31 0) eines kritischen Virus-Zielbereichs und ein 
Identifizierungszeichen (320) enthalt, das eine 
neueste Version der Scan-Engine anzeigt, um 
die Datei auf die Anwesenheit von bosartigem 
Code zu scannen; 

einen Hash-Generator (430), der mit der Daten- 
bank kommuniziert und der so ausgelegt ist, 
dass er einen neuen Hash-Wert des kritischen 
Vim 

ein Selektionsmodul (410), das mit der Daten- 
bank und dem Hash-Generator kommuniziert, 
und so konfiguriert ist, dass es fur jedes Angriffs- 
mittel: 

den neuen Hash-Wert des kritischen Virus-Ziel- 
bereichs mit dem zuvor erzeugten Hash-Wert 
des kritischen Virus-Zielbereichs vergleicht; 
das Identifizierungszeichen der neuesten Ver- 
sion der Scan-Engine, mit der die Datei ges- 
cannt wird, mit dem Identifizierungszeichen der 
neuesten Version der Scan-Engine vergleicht, 
um eine Aktualisierung des Erkennungsmoduls 
einzubeziehen; und 

feststellen, dass die Datei nicht mit einem An- 
griffsmittel infiziert ist, wenn der neue 
Hash-Wert und der zuvor erzeugte Hash-Wert 
identisch sind und die neueste Version der zum 
Scannen der Datei verwendeten Scan-Engine 
keine altere Version als die neueste Version der 
Scan-Engine ist, um eine Aktualisierung des Er- 
kennungsmoduls einzubeziehen. 

12. System nach Anspruch 11, wobei das Selektions- 
modul weiterhin so konfiguriert ist, dass es: 

das Erkennungsmodul auf die Datei anwendet, 
in Antwort auf eine Feststellung, dass die neue- 
ste Version der zum Scannen der Datei verwen- 
deten Scan-Engine eine altere Version als die 
neuste Version der Scan-Engine ist, um eine Ak- 
tualisierung des Erkennungsmoduls einzube- 
ziehen. 

1 3. System nach Anspruch 1 2, weiter umfassend ein Ak- 
tualisierungsmodul (415), das mit der Datenbank 
und mit dem Selektionsmodul kommuniziert und das 
so konfiguriert ist, dass das Identifizierungszeichen 
der neuesten Version der zum Scannen der Datei 
verwendeten Scan-Engine aktualisiert wird, um an- 
zuzeigen, dass die neueste Version der zum Scan- 
nen der Datei verwendeten Scan-Engine die aktuelle 
Version der Scan-Engine ist. 
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14. System nach Anspruch 11, wobei das Selektions- 
modul weiterhin so ausgelegt ist, dass es das Erken- 
nungsmodul auf die Datei anwendet, in Antwort auf 
eine Feststellung, dass fur das entsprechende An- 
griffsmittel der neue Hash-Wert und der zuvor er- 
zeugte Hash-Wert nicht identisch sind. 

15. System nach Anspruch 14, wobei ein Aktualisie- 
rungsmodul (41 5) so konfiguriert ist, dass es die Da- 
tenbank aktualisiert, damit diese den neuen 
Hash-Wert des kritischen Virus-Zielbereichs spei- 
chert. 

16. System nach Anspruch 11, umfassend einen Satz 
einfacher Erkennungsmodule (420), deren Funktion 
darin besteht, Hochgeschwindigkeitsscans auf die 
Datei anzuwenden. 

17. Computerlesbares Medium, das Befehle in Maschi- 
nensprache enthalt, urn ein System so zu steuern, 
dass es samtliche Schritte eines Verfahrens nach 
einem der Anspruche 1 bis 10 ausfuhrt. 

18. Elektrisches Signal, das prozessorimplementierba- 
re Befehle tragt, urn einen Prozessor zu steuern, da- 
mit dieser das Verfahren nach einem der Anspruche 
1 bis 1 0 ausfuhrt. 



Revendications 

1 . Procede de mise en oeuvre d'un systeme (205, 215) 
destine adetecter I'infection d'un fichier informatique 
(340) par I'un quelconque parmi une pluralite 
d'agents agressifs, le procede comprenant les eta- 
pes consistant a : 

generer (51 0) un nouveau hachage d'une region 
cible virale critique du fichier ; et, pour chaque 
agent agressif, realiser les etapes consistant a : 

comparer (540) le nouveau hachage de la 
region cible virale critique aun hachage pre- 
cedemment genere de la region cible virale 
critique ; 

determiner (535) si, oui ou non, le fichier a 
ete examine en vue de la detection d'une 
infection par I'agent agressif avec une ver- 
sion la plus recente d'un module de detec- 
tion respectif (425) ; et 
determiner (542) que le fichier n'a pas ete 
infecte par I'agent agressif quand le nou- 
veau hachage et le hachage precedem- 
ment genere sont identiques et qu'on a de- 
termine que le fichier a ete examine avec la 
version la plus recente du module de detec- 
tion. 



2. Procede selon la revendication 1, comprenant de 
plus I'etape consistant a, pour chaque agent agres- 
sif, appliquer le module de detection au fichier en 
reponse a la determination du fait que le fichier n'a 

5 pas ete examine par la version la plus recente du 

module de detection. 

3. Procede selon la revendication 2, comprenant de 
plus I'etape consistant a, pour chaque agent agres- 

10 sif, mettre a jour un indicateur d'une version la plus 
recente d'un moteur d'examen applique au fichier 
pour indiquer une version courantedu moteur d'exa- 
men. 

15 4. Procede selon la revendication 1 dans lequel I'etape 
consistant a determiner si, oui ou non, le fichier ete 
examine en vue de detecter une infection par I'agent 
agressif avec la version la plus recente du module 
de detection comprend les sous-etapes consistant 

20 a : 

determiner une version la plus recente d'un mo- 
teur d'examen applique au fichier ; 
determiner une version la plus recente du mo- 
25 teur d'examen pour inclure une version mise a 

jour du module de detection ; et 
determiner que le fichier a ete examine avec la 
version la plus recente du module de detection 
quand la version la plus recente du moteur 
30 d'examen applique au fichier n'a pas ete creee 

avant la version la plus recente du moteur d'exa- 
men pour inclure une version mise a jour du mo- 
dule de detection. 

35 5. Procede selon la revendication 1 comprenant de 
plus I'etape consistant a appliquer (525) le module 
de detection au fichier en reponse a une determina- 
tion du fait que le nouveau hachage et le hachage 
precedemment genere ne sont pas identiques. 

40 

6. Procede selon la revendication 5 comprenant de 
plus les etapes consistant a remplacer (549) le ha- 
chage precedemment genere de la region cible vi- 
rale critique par le nouveau hachage de la region 

45 cible virale critique. 

7. Procede selon la revendication 1 dans lequel la re- 
gion cible virale critique comprend une en-tete de 
fichier executable. 

50 

8. Procede selon la revendication 1 dans lequel la re- 
gion cible virale critique comprend un debut d'une 
section de relocalisation. 

55 9. Procede selon la revendication 1 dans lequel la re- 
gion cible virale critique comprend une region situee 
autour d'un point d'entree de programme. 
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10. Procede selon la revendication 1 dans lequel lesdi- 
tes etapes sont precedees par une etape supple- 
mentaire consistant a realiser un ensemble d'exa- 
mens a haute Vitesse sur le fichier en utilisant un 
ensemble correspondant de modules de detection 5 
simples (420). 

1 1 . Systeme destine a detecter une infection d'un fichier 
informatique (340) par Tun quelconque parmi une 
pluralite d 'agents agressifs, le systeme 10 
comprenant : 

une pluralite de modules de detection (425), 
chacun de ces modules etant configure pour ve- 
rifier le fichier informatique en vue de detecter is 
une infection par I'un respectif des agents agres- 
sifs, le module de detection comprenant un iden- 
tifiant d'une version la plus recente d'un moteur 
d'examen (205) pour inclure une mise a jour vers 
le module de detection ; 20 
une base de donnees (215), en communication 
avec les modules de detection, et stockant des 
entrees, chaque entree etant associee a un fi- 
chier (340) et contenant un hachage precedem- 
ment genere (31 0) d'une region cible virale cri- 25 
tique et un identif iant (320) indiquant une version 
la plus recente du moteur d'examen pour exa- 
miner le fichier en vue de detecter la presence 
d'un code malveillant ; 

un generateur de hachage (430), en communi- 30 
cation avec la base de donnees, et configure 
pour generer un nouveau hachage de la region 
cible virale critique; 

un module de selection (410), en communica- 
tion avec la base de donnees et le generateur 35 
de hachage, et configure pour chaque agent 
agressif pour : 

comparer le nouveau hachage de la region 
cible virale critique au hachage precedem- 40 
ment genere de la region cible virale 
critique ; 

comparer I'identifiant de la version la plus 
recente du moteur d'examen pour examiner 
le fichier en ce qui concerne I'identifiant de 45 
la version la plus recente du moteur d'exa- 
men pour inclure une mise a jour du module 
de detection ; et 

determiner que le fichier n'a pas ete infecte 
parun agent agressif quand le nouveau ha- 50 
chage et le hachage precedemment genere 
sont identiques et quand la version la plus 
recente du moteur d'examen pour examiner 
le fichier n'est pas une version plus ancien- 
ne que la version la plus recente du moteur 55 
d'examen pour inclure une mise a jour du 
module de detection. 



12. Systeme selon la revendication 11 dans lequel le 
module de selection est de plus configure pour : 

appliquer le module de detection au fichier en 
reponse a une determination du fait que la ver- 
sion la plus recente du moteur d'examen pour 
examiner le fichier est une version plus ancienne 
que la version la plus recente du moteur d'exa- 
men pour inclure une mise a jour du module de 
detection. 

13. Systeme selon la revendication 12, comprenant de 
plus un module de mise a jour (415), en communi- 
cation avec la base de donnees et avec le module 
de selection, et configure pour mettre a jour I'identi- 
fiant de la version la plus recente du moteur d'exa- 
men pour examiner le fichier pour indiquer que la 
version la plus recente du moteur d'examen pour 
examiner le fichier est la version courantedu moteur 
d'examen. 

14. Systeme selon la revendication 11 dans lequel le 
module de selection est de plus configure pour ap- 
pliquer le module de detection au fichier en reponse 
a une determination pour I'agent agressif respectif 
du fait que le nouveau hachage et le hachage pre- 
cedemment genere ne sont pas identiques. 

15. Systeme selon la revendication 14 dans lequel un 
module de mise a jour (415) est configure pour met- 
tre a jour labase de donnees pour stocker le nouveau 
hachage de la region cible virale critique. 

16. Systeme selon la revendication 11 comprenant un 
ensemble de modules de detection simples (420) 
utilisables pour realiser des examens a haute Vitesse 
sur le fichier. 

17. Support lisible par ordinateur contenant des instruc- 
tions de code informatique destinees a commander 
un systeme pour executertoutes les etapes d'un pro- 
cede selon Tune quelconque des revendications 1 a 
10. 

18. Signal electrique portantdes instructions realisables 
par un processeur destinees a commander un pro- 
cesseur pour executer le procede selon I'une quel- 
conque des revendications 1 a 10. 
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